Exemplary embodiments relate to change management in multi-domain environments, and more specifically, to managing change across organizational boundaries.
Distributed systems increasingly span organizational boundaries, and with this, system and service management domains. Examples are Web service-based integration of electronic commerce solutions, the integration of Software-as-a-Service (SaaS) with customer managed applications and mashups, and the use of Cloud based resources on an infrastructure level or on a platform level. Maturing cross-domain relationships and an increase in loose coupling and ad-hocness make managing configuration changes, e.g., changes in interfaces or endpoints, increasingly relevant. Traditional service management processes, in particular change management, rely on a central configuration management database (CMDB) to assess the impact of a change to other components of the system. However, this approach does not work in a cross-domain environment without central CMDB, without centralized management processes, and often without understanding of the party providing a service and the clients who depend on it.
Also, in an environment of software as a service, cloud computing, Web 2.0 and the like, organizations are increasingly dependent on information technology (IT) and communication infrastructure they do not own and manage. There are often complex dependency relationships between services hosted by a service provider and internal systems such as an SaaS provider hosting a sales application while authorizing users with a lightweight directory access protocol (LDAP) system that its customer organization manages. In current IT practice, changes to a system infrastructure, which are inevitable, will be managed using a change management process. This process will assess the impact on all systems concerned in an organization, develop a change plan, schedule the change, test it and then roll it out. The crucial impact assessment is typically based on a central configuration management database (CMDB) from which dependencies can be derived. However, in an environment in which services of different service providers and their customers are meshed together, this traditional change management approach cannot consider impact on infrastructure outside one organization's management domain since it is not represented in a CMDB. A cloud provider does not know what runs on its hypervisors, and hence, which business processes will be affected in the operations of its clients. Hence, the affected systems in other organizations are not known. Furthermore, separate organizations run different change processes and change management systems.